I would like to know what the keyword try is used for in Specman and especially its usage in the code snippet given below:
try {
unpack(packing.low,lob,pkt);
} else{
message(LOW, “Uh-oh!”){print lob using HEX;};
message(LOW,”bad unpack!!!”);
};
try and if are similar where if executes the true block when the condition is true
and else it executes the false.
similarly try also if there is an error in the true block it switches to else block.
try and else are Specman's exception handling constructs. If an error is created in the try block, then the else block is immediately executed instead of the rest of the try block and the error is suppressed with no printout.
In this case, if lob has more bits than pkt has "physical fields", then the unpack will generate an error. If that happens, the Specman runtime will jump to the else block and print out the lob data structure instead of printing the original unpack error. Look in the docs with regards to what "physical fields" are and how they are used. They are a strange construct that specifically interacts with the behavior of Specman's %, pack, and unpack constructs. Physical fields of pkt will be declared with the % modifier preceding the "physical fields" of pkt.
Related
I am trying to code simple program in C which writes and reads something from Windows registry. What does the return value of 7 for RegOpenKeyEx mean?
I am having a hard time trying to guess it. Yes, MSDN says I can use FormatMessage to examine it, but it takes 7 arguments and I have no idea how to use it... (what an awful api design by the way).
The MSDN entry for RegOpenKeyEx also indicates that:
If the function fails, the return value is a nonzero error code defined in Winerror.h.
Those error codes are documented in MSDN - System Error Codes page. If you really are getting 7, then this error would correspond to:
ERROR_ARENA_TRASHED
7 (0x7)
The storage control blocks were destroyed.
What it means could range from your registry being corrupted, to a slew of program errors resulting in seemingly weird behavior, or to simply that you are getting something else as a return value and are lead to believe you are getting a result of 7. Without a more complete code example, it is hard to venture anything more specific.
P.S.: FormatMessage is mostly handy if you are trying to obtain a string representation of the error at run time. If that's the case, you can refer to this answer for an example on how to use it.
I took a look at this question and believe I understand the solution, except for the following:
try get_all_lines(Device)
after file:close(Device)
end.
Looking in the documentation, specifically the 7.19 Try section, it looks like one would typically use after clauses as a failsafe block to execute regardless of the execution of a conditional block. If that is a correct assumption, why would the given example use after when, not only is there not a conditional block, there's not a block at all! It just looks like the try get_all_lines(Device) block is completely empty, and an unnecessary after clause was appended. Am I misinterpreting the example, or could this code be written better?
The block isn't empty, it contains a single function call: get_all_lines(Device). If io:get_line inside this function throws an exception (e.g. because the file was deleted while reading it, then get_all_lines will throw as well, and you need to close the file both in this case and when the function returns without an exception. This is precisely what after is for.
I have a 132 kb file (you can't really say it's big) and I'm trying to read it from the Scala REPL, but I can't read past 2048 char because it gives me a java.nio.charset.MalformedInputException exception
These are the steps I take:
val it = scala.io.Source.fromFile("docs/categorizer/usig_calles.json") // this is ok
it.take(2048).mkString // this is ok too
it.take(1).mkString // BANG!
java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(CoderResult.java:277)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:338)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
Any idea what could be wrong?
--
Apparently the problem was that the file was not UTF encoded
I saved it as UTF and everything works, I just issue mkString on the iterator and it retrieves the whole contents of the file
The strange thing is that the error only aroused passing the first 2048 chars...
Cannot be certain without the file, but the documentation on the exception indicates it is thrown "when an input byte sequence is not legal for given charset, or an input character sequence is not a legal sixteen-bit Unicode sequence." (MalformedInputException javadoc)
I suspect that at 2049 is the first character encountered that is not valid with whatever the default JVM character encoding is in you environment. Consider explicitly stating the character encoding of the file using one of the overloads to fromFile.
If the application will be cross platform, you should know that the default character encoding on the JVM does vary by platform, so if you operate with a specific encoding you either want to explicitly set it as a command line parameter when launching of your application, or specify it at each call using the appropriate overload.
Any time you call take twice on the same iterator, all bets are off. Iterators are inherently imperative, and mixing them with functional idioms is dicey at best. Most of the iterators you come across in the standard library tend to be fairly well-behaved in this respect, but once you've used take, or drop, or filter, etc., you're in undefined-behavior land, and in principle anything could happen.
From the docs:
It is of particular importance to note that, unless stated otherwise,
one should never use an iterator after calling a method on it. The two
most important exceptions are also the sole abstract methods: next
and hasNext ...
def take(n: Int): Iterator[A] ...
Reuse: After calling this method, one should discard the iterator it
was called on, and use only the iterator that was returned. Using the
old iterator is undefined, subject to change, and may result in
changes to the new iterator as well.
So it's probably not worth trying to track down exactly what went wrong here.
If you just wish to convert the bytes to plain Latin data:
// File:
io.Source.fromFile(file)(io.Codec.ISO8859).mkString
// InputStream:
io.Source.fromInputStream(System.io)(io.Codec.ISO8859).mkString
I'm using PC Lint for the first time. I was "linting" my code, when PC Lint warns me about my while(TRUE).
This is what it says:
716: while(1) ... -- A construct of the form while(1) ... was found.
Whereas this represents a constant in a context expecting a Boolean,
it may reflect a programming policy whereby infinite loops are
prefixed with this construct. Hence it is given a separate number and
has been placed in the informational category. The more conventional
form of infinite loop prefix is for(;;).
I didn't understand this statement. Can anyone help me to understand it?
The text says that although while(TRUE) (which gets preprocessed into while(1)) is a perfectly valid infinite loop, the more conventional form of writing an infinite loop is
for(;;)
{
...
}
because it doesn't use any values at all and therefore is less error-prone.
It says that the more conventional infinite loop is for(;;), which I'd say is an arguable assertion, and that it's categorized this construct as an "informational category" finding - I suspect that if you used the for(;;) instead it would go away. I've always written these as while(1) and never for(;;) myself. If it does what you expect, I'd ignore the findings of PC LINT on this one or switch it if you're worried about someone redefining TRUE because if someone redefined TRUE your loop wouldn't run at all.
I return a error code if my program was abnormally terminated (via exit()). For standard situations, I just return the underlying errno (for example, ENOMEM for failed mallocs etc). There are, however, also cases when I'll have to terminate due to my own reasons for which there are no system errnos defined.
What error values should I return so that they do not clash with the existing ones. Or am I doing the whole thing assbackwards?
edit: I am sorry if I was not clear with the question. I am not talking about enum etc (they are the mechanism for defining error codes). I was talking of the range of values they could take without clashing with the standard ones.
What I didn't know was that the program can only return 8 bit statuses. So it seems like #r is correct - that is a bit too small to accomodate maybe even all the standard ones, let alone my custom errors. so 1/0 it is :)
The width of the return code is usually pretty small, for example limited to 8 bits, so it's hard to store a lot of information in it. Really I wouldn't bother with exit codes besides 0/1 (success/failure) unless your program is intended for use in shell scripting, in which case you probably just need to figure out the error cases a potential shell script might need to check for and distinguish them (for example, "no match" versus "resource exhausted while searching").
What error values should I return so that they do not clash with the existing ones. Or am I doing the whole thing assbackwards?
Keep it simple. The most important test for error codes (that is also valid for plain functions) is what the caller can do about it. I have seen projects were people were introducing hundreds/thousands error code for all unique cases what in the end led to the total mess in the error handling (they were trying to give every function/SQL statement a unique exit code). And that - error handling - is precisely the party concerned with the exit codes.
My personal rule for return codes is to make sure that they are useful to the error handling. To exemplify, for a batch program I might have peeked the status codes like that:
0 - O.K.,
1 - internal but probably recoverable error (e.g. memory allocation error, kill other batches and try to restart),
2 - fatal error in config (restart will not help),
3 - fatal error in input data (replace input, try again),
4 - output got disk full error (clean /tmp, try again).
That is only an example to highlight that the error codes should be thought about from POV of the caller, not callee. If for example, full/partial automation isn't a target and users have to analyze log files anyway, then returning 0 or 1 would also suffice.
Have you considered using enum to define error codes?
Anyway, here is an interesting discussion about it.
There are few ways to do it.
1) Enums - This can be done in the following way. There is flexibility to add different error codes as and when you need and put them in a group. Say errors related to user authentication, file access, API errors etc.
enum
{
ERROR_GROUP_1 =100,// This gives 99 error codes for a particular group, can be initialised to negative value too.
GROUP1_1,
.
.
ERROR_GROUP_2 = 200
GROUP2_2,
.
.
and so on
};
2) Use pre-processor directives
#define ERROR_CODE_START 00000000L
#define ERROR_CODE_1 (ERROR_CODE_START + 1)
3) Negative return values as int but this will be lot of pain as the reference should be well documented for the values.
4) You can create a structure like GError. Pass a reference to this structure in every API and fill this. If its not NULL then the caller can check the error code and string which will be set in the API.
On a Posix compliant system, there is absolutely no point in returning any number outside the range 0 to 255. This is because the wait() system call only lets you have the bottom eight bits of the return value of your program (or possibly 16 bits).
In practice, you probably just want a handful of codes, maybe just 0 and 1. Further information can be communicated via stderr in a more useful (to a human) text format.