Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Can I assume fgets won't modify last bytes of output array if unused ?

Reply
Thread Tools

Can I assume fgets won't modify last bytes of output array if unused ?

 
 
Tim Rentsch
Guest
Posts: n/a
 
      01-02-2011
Eric Sosman <(E-Mail Removed)> writes:

> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>> Hello,
>>
>> I think this is undefined behaviour, but I prefer asking just in case
>> I'm missing something.
>>
>> Consider that a line is 8 characters long (including newline) and I pass
>> to fgets a buffer which can store at least 32 characters.
>>
>> Can I assume that if fgets reads that line, then it won't modify any
>> characters in the buffer whose offset is greater than 8 ?

>
> As I understand it, fgets() is allowed to scribble on any or all
> of the buffer's bytes, except that if there's an immediate end-of-file
> it will touch none of them.


I don't see any text in the Standard that would allow an
implementation to do this. I believe Mark Wooding's reading
on this question is the correct one here.
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-02-2011
On 1/2/2011 4:00 AM, Tim Rentsch wrote:
> Eric Sosman<(E-Mail Removed)> writes:
>
>> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>>> Hello,
>>>
>>> I think this is undefined behaviour, but I prefer asking just in case
>>> I'm missing something.
>>>
>>> Consider that a line is 8 characters long (including newline) and I pass
>>> to fgets a buffer which can store at least 32 characters.
>>>
>>> Can I assume that if fgets reads that line, then it won't modify any
>>> characters in the buffer whose offset is greater than 8 ?

>>
>> As I understand it, fgets() is allowed to scribble on any or all
>> of the buffer's bytes, except that if there's an immediate end-of-file
>> it will touch none of them.

>
> I don't see any text in the Standard that would allow an
> implementation to do this. I believe Mark Wooding's reading
> on this question is the correct one here.


Can you find any text that forbids it?

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-02-2011
Eric Sosman <(E-Mail Removed)> writes:
> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>> Eric Sosman<(E-Mail Removed)> writes:
>>
>>> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>>>> Hello,
>>>>
>>>> I think this is undefined behaviour, but I prefer asking just in case
>>>> I'm missing something.
>>>>
>>>> Consider that a line is 8 characters long (including newline) and I pass
>>>> to fgets a buffer which can store at least 32 characters.
>>>>
>>>> Can I assume that if fgets reads that line, then it won't modify any
>>>> characters in the buffer whose offset is greater than 8 ?
>>>
>>> As I understand it, fgets() is allowed to scribble on any or all
>>> of the buffer's bytes, except that if there's an immediate end-of-file
>>> it will touch none of them.

>>
>> I don't see any text in the Standard that would allow an
>> implementation to do this. I believe Mark Wooding's reading
>> on this question is the correct one here.

>
> Can you find any text that forbids it?


6.2.4p2:

An object exists, has a constant address, and retains its
last-stored value throughout its lifetime.

This applies to each element of the buffer past the ones into which
fgets() stores values.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-03-2011
On 1/2/2011 2:16 PM, Keith Thompson wrote:
> Eric Sosman<(E-Mail Removed)> writes:
>> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>>> Eric Sosman<(E-Mail Removed)> writes:
>>>
>>>> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>>>>> Hello,
>>>>>
>>>>> I think this is undefined behaviour, but I prefer asking just in case
>>>>> I'm missing something.
>>>>>
>>>>> Consider that a line is 8 characters long (including newline) and I pass
>>>>> to fgets a buffer which can store at least 32 characters.
>>>>>
>>>>> Can I assume that if fgets reads that line, then it won't modify any
>>>>> characters in the buffer whose offset is greater than 8 ?
>>>>
>>>> As I understand it, fgets() is allowed to scribble on any or all
>>>> of the buffer's bytes, except that if there's an immediate end-of-file
>>>> it will touch none of them.
>>>
>>> I don't see any text in the Standard that would allow an
>>> implementation to do this. I believe Mark Wooding's reading
>>> on this question is the correct one here.

>>
>> Can you find any text that forbids it?

>
> 6.2.4p2:
>
> An object exists, has a constant address, and retains its
> last-stored value throughout its lifetime.
>
> This applies to each element of the buffer past the ones into which
> fgets() stores values.


Doesn't seem convincing, because it also applies to the elements
fgets() *does* store to.

Here's a synopsis of my thinking, for what it's worth: When
you call fgets(buff, 100, stream) you give fgets() permission to
write on all of buff[0] through buff[99] -- and, given enough input,
fgets() will certainly do so. Aside from the special handling of
end-of-input, I see no language in the Standard that says buff[42]
must be left untouched, and no description of circumstances that
would put buff[42] off-limits. Do you see such language?

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2011
Eric Sosman <(E-Mail Removed)> writes:
> On 1/2/2011 2:16 PM, Keith Thompson wrote:
>> Eric Sosman<(E-Mail Removed)> writes:
>>> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>>>> Eric Sosman<(E-Mail Removed)> writes:
>>>>
>>>>> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I think this is undefined behaviour, but I prefer asking just in case
>>>>>> I'm missing something.
>>>>>>
>>>>>> Consider that a line is 8 characters long (including newline) and I pass
>>>>>> to fgets a buffer which can store at least 32 characters.
>>>>>>
>>>>>> Can I assume that if fgets reads that line, then it won't modify any
>>>>>> characters in the buffer whose offset is greater than 8 ?
>>>>>
>>>>> As I understand it, fgets() is allowed to scribble on any or all
>>>>> of the buffer's bytes, except that if there's an immediate end-of-file
>>>>> it will touch none of them.
>>>>
>>>> I don't see any text in the Standard that would allow an
>>>> implementation to do this. I believe Mark Wooding's reading
>>>> on this question is the correct one here.
>>>
>>> Can you find any text that forbids it?

>>
>> 6.2.4p2:
>>
>> An object exists, has a constant address, and retains its
>> last-stored value throughout its lifetime.
>>
>> This applies to each element of the buffer past the ones into which
>> fgets() stores values.

>
> Doesn't seem convincing, because it also applies to the elements
> fgets() *does* store to.


No, it doesn't; those elements get *new* last-stored values.

> Here's a synopsis of my thinking, for what it's worth: When
> you call fgets(buff, 100, stream) you give fgets() permission to
> write on all of buff[0] through buff[99] -- and, given enough input,
> fgets() will certainly do so. Aside from the special handling of
> end-of-input, I see no language in the Standard that says buff[42]
> must be left untouched, and no description of circumstances that
> would put buff[42] off-limits. Do you see such language?


No, but I don't think such language is necessary.

Any library function does what it's specified to do, and no more
(at least no more that's visible). sqrt() doesn't write to stdout,
for example, even though nothing in the standard explicitly says
it doesn't.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      01-03-2011
> Can I assume that if fgets reads that line, then it won't modify any
> characters in the buffer whose offset is greater than 8 ?


Any time you're working with computers, and the word 'assume' comes up,
I hope all the hair stands up on the back of your neck.

No, you may not assume this, unless the man page explicitly says so.
Then it wouldn't be an assumption.
--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2011
(E-Mail Removed) (Edward A. Falk) writes:
>> Can I assume that if fgets reads that line, then it won't modify any
>> characters in the buffer whose offset is greater than 8 ?

>
> Any time you're working with computers, and the word 'assume' comes up,
> I hope all the hair stands up on the back of your neck.
>
> No, you may not assume this, unless the man page explicitly says so.
> Then it wouldn't be an assumption.


I disagree.

First, what a man page says isn't necessarily relevant; fgets()
is defined by the ISO C Standard. (If a particular man page says
something that's inconsistent with the standard, it may be either
an error in the man page or an admission of non-conformance.)

My own interpretation of the C standard is, in the absence of
I/O errors, fgets() may not write past the characters that it's
specified to read -- any more than it may write to any other object.

As I mentioned elsethread, I feel perfectly comfortable *assuming*
that sqrt() doesn't write to stdout, even though there's no explicit
statement that it doesn't do so.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-04-2011
Eric Sosman <(E-Mail Removed)> writes:

> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>> Eric Sosman<(E-Mail Removed)> writes:
>>
>>> On 12/17/2010 5:26 AM, Francis Moreau wrote:
>>>> Hello,
>>>>
>>>> I think this is undefined behaviour, but I prefer asking just in case
>>>> I'm missing something.
>>>>
>>>> Consider that a line is 8 characters long (including newline) and I pass
>>>> to fgets a buffer which can store at least 32 characters.
>>>>
>>>> Can I assume that if fgets reads that line, then it won't modify any
>>>> characters in the buffer whose offset is greater than 8 ?
>>>
>>> As I understand it, fgets() is allowed to scribble on any or all
>>> of the buffer's bytes, except that if there's an immediate end-of-file
>>> it will touch none of them.

>>
>> I don't see any text in the Standard that would allow an
>> implementation to do this. I believe Mark Wooding's reading
>> on this question is the correct one here.

>
> Can you find any text that forbids it?


I believe there is no reason to look for any. Library
functions _must_ do what their respective specifications
require them to do, and _may_ do what the Standard
explicitly grants them license to do. This principle
also holds more generally; for example, storing into
a structure member is explicitly permitted to change
the contents of padding bytes. So unless there is some
text that explicitly provides for changing some array
elements past those that were read, the implementation
is obliged not to change them.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Date#parse assume a EU format - can it assume a US format? Josh Sharpe Ruby 1 09-21-2010 09:16 AM
file.seek and unused bytes Greg Willits Ruby 39 07-07-2009 07:16 PM
Can I assume the memory is continuous? linq936 C++ 21 09-19-2007 12:12 PM
Could a struct with size 44 bytes point always points to a char array with size 2024 bytes? eagle_jyjh@citiz.net C++ 8 04-10-2006 03:05 PM
Could a struct with size 44 bytes point always points to a char array with size 2048 bytes? eagle_jyjh@citiz.net C Programming 5 04-09-2006 02:49 PM



Advertisments