Some suggested corrections to the standards document

View: New views
6 Messages — Rating Filter:   Alert me  

Some suggested corrections to the standards document

by Eugene Y. Vasserman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,
I've been reading the GNU coding standards, and I think I have some ways to make certain things clearer.

1. You frequently refer to RAM as core. I think this is an outdated term, and many modern programmers may not know what it means. I would suggest replacing core with RAM or main memory.

2. In section 5.6, there is a short bit of text:
Don't assume that the address of an int object is also the address of its least-significant byte. This is false on big-endian machines. Thus, don't make the following mistake:

     int c;
     ...
     while ((c = getchar()) != EOF)
       write(file_descriptor, &c, 1);

a. You may want to change the code to be GNU coding standards complient (as per section 5.3) other than the bug being demonstrated, otherwise the reader may be confused. So, the code in question should be:
     int c;
     ...
          c = getchar();
     while (c != EOF)
          {
       write(file_descriptor, &c, 1);
            c = getchar();
     }
Thus the bug in question is preserved, and the code does not confuse the user about other standards.

b. It would be good to include the correct way of doing what the code should be doing. This way, the reader may learn better from this example. :)

Thanks,
Eugene

--
Eugene Y. Vasserman
http://www.cs.umn.edu/~eyv/



Re: Some suggested corrections to the standards document

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Eugene,

    1. You frequently refer to RAM as core. I think this is an outdated
    term, and many modern programmers may not know what it means. I
    would suggest replacing core with RAM or main memory.

Thanks for the suggestion.  Isn't the meaning clear from the context?
But I'll suggest to rms that we change the term, anyway.

          c = getchar();
     while (c != EOF)
          {
       write(file_descriptor, &c, 1);
            c = getchar();

Actually, the 5.3 section you refer to talks specifically about
if-conditions.  Not while-conditions.  Assignments in while-conditions
are ok (as far as I know), precisely to avoid the kind of code
duplication you had to write above.

However, there should be a space after "write" and "getchar", per 5.1 :).

    b. It would be good to include the correct way of doing what the
    code should be doing. This way, the reader may learn better from
    this example. :)

True enough.  I have to shame-facedly confess that I'm not sure of the
recommended way to write it.  Introduce a char variable, like the below?
Use a cast somehow?  Paul?

     int c;
     ...
     while ((c = getchar ()) != EOF)
       {
         char c_for_write = c;
         write (file_descriptor, &c_for_write, 1);
       }

Thanks for writing,
Karl



Re: Some suggested corrections to the standards document

by Paul Eggert :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

karl@... (Karl Berry) writes:

> True enough.  I have to shame-facedly confess that I'm not sure of the
> recommended way to write it.  Introduce a char variable, like the below?
> Use a cast somehow?  Paul?

What you had was the right idea, except it should use unsigned char
instead of char, to be portable to (admittedly weird) systems where
char is signed and there's integer overflow checking so an exception
is raised when storing (say) 255 into a char variable.  So this is a
bit better:

  int c;
  while ((c = getchar ()) != EOF)
    {
      unsigned char u = c;
      write (file_descriptor, &u, 1);
    }



Re: Some suggested corrections to the standards document

by Eugene Y. Vasserman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The GNU document already states not to do the error check inline, so
this should really be:
int c;
c = getchar();
while (c != EOF)
{
   unsigned char u = c;
   write (file_descriptor, &u, 1);
   c = getchar();
}
This, of course, assumes that we are in fact reading a character buffer.
If we were reading an arbitrary stream, we should check for end-of-file
with the eof() call.

Thus spake Paul Eggert:

> karl@... (Karl Berry) writes:
>
>> True enough.  I have to shame-facedly confess that I'm not sure of the
>> recommended way to write it.  Introduce a char variable, like the below?
>> Use a cast somehow?  Paul?
>
> What you had was the right idea, except it should use unsigned char
> instead of char, to be portable to (admittedly weird) systems where
> char is signed and there's integer overflow checking so an exception
> is raised when storing (say) 255 into a char variable.  So this is a
> bit better:
>
>   int c;
>   while ((c = getchar ()) != EOF)
>     {
>       unsigned char u = c;
>       write (file_descriptor, &u, 1);
>     }

--
Eugene Y. Vasserman
http://www.cs.umn.edu/~eyv/



Re: Some suggested corrections to the standards document

by Paul Eggert :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

"Eugene Y. Vasserman" <eyv@...> writes:

> If we were reading an arbitrary stream, we should check for end-of-file
> with the eof() call.

It's not intended to be a treatise on stdio, and it would be overkill
to rewrite it to be that way.  It's merely a comment on endianness.

> The GNU document already states not to do the error check inline

I don't know what you mean by "inline".  The word isn't used in that
sense in standards.texi.  But at this point I think it doesn't matter.



Re: Some suggested corrections to the standards document

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


    The GNU document already states not to do the error check inline, so

As I said before, the bit about assignments applies to if-conditions,
not while-conditions.  Duplicating code is (almost) never a good idea.

Thanks for the unsigned char stuff, Paul.

I'm sending a proposed change to rms now.

Best,
Karl