Title: Briefs

This is a new, and I hope regular column in which I will publish contributions from members that are substantially less than a page in length. That means that readers who are short of time to write a full article will still have a chance of experiencing that warm feeling of seeing their by-line in print.

I recently came across some code with something like

x=y+isspace(ch);

This is similar to a BBC BASIC trick that assumes a boolean function returning an integer will always return the same value for true (in this case 1). It doesn't work in C because functions like this are only guaranteed to return non-zero, not 1, when they mean 'true', and in particular the is... functions are often implemented by taking an array element that gives all the attributes of the character as a bit pattern and ANDing it with the required bits before returning the result. This makes them fast (an indexed load and an AND is quicker than lots of 'if' statements) but it also means that the value returned can be anything (I tried it on three different versions of gcc and got three different results). By not defining it to be 1 or 0, the standard has allowed for such optimisations. If you want it to be 1 or 0, you would have to write (isspace(ch)?1:0) and similarly for other functions.

On the subject, did you know that the is... functions are undefined on EOF? The same code had a while(isalpha()) loop that evidently assumed that EOF would fail it. In the sample implementation described above, EOF is outside the bounds of the array and what the function will return depends on what rubbish there is in the appropriate memory location. If you want to bounds-check an is... parameter then first call isascii().

Are there any differences between C and C++ in this context? No, I am not telling, find out and write it up.

Never assume that your compiler obeys the standard, no matter how reputable it is. I've just spent my afternoon trying to get my access gateway working on a web server at Edinburgh University, because there was interest in a local version there (thanks to telnet I didn't have to leave Cambridge). The server was a Sun Unix machine, not Intel, with a not-too-well set-up version of g++; I had to do some patching to get it to work and when it did work, the program wouldn't run. I eventually tracked the problem down to vsprintf() not returning what it is defined to return (even in Sun's and gcc's own documentation) - the number of characters output, or <0 for an error. Instead, it returned some incredibly huge positive value that caused a rogue memory overwrite. Re-writing that section of code to avoid the use of vsprintf()s return value fixed the problem.

It would be good if someone could write a "standards benchmark" program that, when compiled with an arbitrary compiler and run, will report any deviations from the standard (or indeed anything that does conform to the standard but is not usual) so programmers attempting to port code to it will know precisely what to expect. Perhaps ACCU could do this as an organisation, with those members who are interested contributing and discussing their code?

Well such programs exist but are immensely expensive (they are conformance test suites). The specific problem here reminds me of problems where there is a conversion from a signed integer type to an unsigned one. I wonder if some such was hiding in the code.

Did you know that the GNU C and C++ compilers under Unix have built-in profilers? If you compile with the -pg switch, your executable will generate a file gmon.out. If the executable itself is called a.out then you can just type gprof|more to view the profile. The first functions or methods that it lists are likely to be the bottlenecks.