[PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo

Peter Rosin peda at lysator.liu.se
Mon Nov 29 01:46:15 CST 2010

Den 2010-11-29 08:36 skrev Peter Rosin:
> Den 2010-11-29 01:03 skrev James Eder:
>> On 11/26/10 12:15 AM, Damjan Jovanovic wrote:
>>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen
>>> <wine-devel at kievinfo.com>  wrote:
>>>> On 11/24/2010 07:19 PM, James McKenzie wrote:
>>>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote:
>>>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote:
>>>>>>> From: James Eder<jimportal at gmail.com>
>>>>>>> - while (fgets(line,200,f) != NULL)
>>>>>>> + while (fgets(line,450,f) != NULL)
>>>>>> You might as well then change this to "sizeof(line)".
>>>>> Just for my edification, is there not a better way then setting the
>>>>> variable
>>>>> line to a flexible length for this purpose.
>>>> Unless I didn't understand your question - you can't set a buffer to a
>>>> "variable length". You have to provide fgets() a size of the buffer so it
>>>> can read at most that many characters -1 for terminating \0.
>>>> Vitaliy.
>>> So read lines dynamically instead:
>> It would be nice to not reinvent that wheel all the time.  I don't
>> suppose your function could be pulled out of winemenubuilder.c and
>> placed in a more accessible location.  Should I just copy and paste
>> it?  It's a good function and it would fit just fine in my opinion.
>> Alternatively, I doubt 2k or 4k worth of processor features ("flags")
>> are going to show up for some years, but I don't know.  At any rate,
>> at least it would fix it for current systems.
> I'm just making a note that the fgets function is not very well suited
> for CRNL style line endings.  In the cases discussed here, you appear to
> only handle linux files with NL style line endings, but if you ever try
> to handle CRNL files, fgets may read CR as the last character on one
> invocation and then forget that until the next invocation and thus fail
> to find the line ending.  The proposed function a few messages back
> would in that case read two lines into the buffer, and they would be
> separated by a CR.
> For this reason, I consider fgets completely unusable (on Windows) for
> anything where the maximum line length isn't known in advance.
> But maybe wine does not have this problem?  However, my XP SP3 sure does.

Scratch that, it appears to behave.  I must have screwed up my previous

However, I do remember fgets misbehavior on Windows.


More information about the wine-devel mailing list