«

Eric Sosman <> 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.

On 1/2/2011 4:00 AM, Tim Rentsch wrote:
> Eric Sosman<> 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
lid

Eric Sosman <> writes:
> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>> Eric Sosman<> 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) kst- <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"

On 1/2/2011 2:16 PM, Keith Thompson wrote:
> Eric Sosman<> writes:
>> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>>> Eric Sosman<> 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
lid

Eric Sosman <> writes:
> On 1/2/2011 2:16 PM, Keith Thompson wrote:
>> Eric Sosman<> writes:
>>> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>>>> Eric Sosman<> 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) kst- <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"

> 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,
http://thespamdiaries.blogspot.com/

(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) kst- <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"

Eric Sosman <> writes:

> On 1/2/2011 4:00 AM, Tim Rentsch wrote:
>> Eric Sosman<> 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.