getdelim：错误的规格 [英] getdelim: wrong specs
问题描述
在波特兰会议中提交的文件
的C标准委员会
http://www.open-std.org/jtc1/sc22/wg14/
有一个名为ISO / IEC WDTR 24731-2的文件，
更安全的C库函数规范a ??
第二部分：动态分配函数
在该文档中，我们有：
ssize_t getdelim（char **限制lineptr，
size_t * restrict n，int delimiter，FILE * stream）;
我们读到：
<引用>
成功完成后，getdelim函数将返回写入缓冲区的字符数
，包括分隔符字符
$ b如果在EOF之前遇到一个，则为$ b。否则它将返回?? 1。
<结束报价>
我们回到这里来看错误分析问题，这个问题我已经提到了很多年以来一直在提及的问题。返回
-1表示发生了一些错误，但我不会告诉你哪个
是糟糕的设计！
此函数可能有多个错误，应该在函数的返回值中区分，即应该有其他返回
值用于向用户发送信号错误。 Lcc-win32实现了这个
函数并返回：
-5没有内存可用于分配行
-4行指针指向一个缓冲区，但是n是< = 0.这是传入参数的错误。
-3 n参数为NULL
-2 LinePointer参数为NULL
-1没有读取任何字符的文件结尾。
这是一个更详细的错误报告，允许
用户的功能可以区分不同的错误
条件。令人遗憾的是，提出更安全的文件令人遗憾。函数
不做错误分析，这是更安全
编程的重要部分。
In the documents presented in the post Portland meeting
of the C standards comitee
http://www.open-std.org/jtc1/sc22/wg14/
there is a document called ISO/IEC WDTR 24731-2,
Specification for Safer C Library Functions a??
Part II: Dynamic Allocation Functions
In that document we have:
ssize_t getdelim(char **restrict lineptr,
size_t *restrict n, int delimiter, FILE *stream);
We read:
< quote >
Upon successful completion the getdelim function shall return the number
of characters written into the buffer, including the delimiter character
if one was encountered before EOF. Otherwise it shall return a??1.
< end quote >
We come back here to the error analysis problem, a problem that I
have been mentioning since ages and comes again and again. Returning
-1 to indicate "some error occurred but I will not tell you which"
is BAD DESIGN!
This function can have several errors that should be distinguished in
the return value of the function, i.e. there should be other return
values for signaling errors to the user. Lcc-win32 implements this
function and returns:
-5 No memory left for allocating the line
-4 Line pointer points to a buffer but n is <= 0. This is an error in
the incoming arguments.
-3 The n parameter is NULL
-2 The LinePointer parameter is NULL
-1 End of file without any characters read.
This is a much more detailed error reporting, that allows the
user of the function to discriminate between the different error
conditions. It is sad that a document that proposed "safer" functions
doesn''t do the error analysis that is an essential part of safer
programming.
推荐答案
jacob navia写道：
jacob navia wrote:
>
在波特兰会议中提交的文件中
$ b C标准委员会的$ b
http：// www.open-std.org/jtc1/sc22/wg14/
有一份名为ISO / IEC WDTR 24731-2的文件，
更安全的C库函数规范a ??
第二部分：动态分配函数
在该文档中我们有：
ssize_t getdelim（char **限制lineptr，
size_t * restrict n，int delimiter，FILE * stream）;
我们读到：
<引用>
成功完成后，getdelim函数将返回写入缓冲区的字符数
，包括分隔符字符
$ b如果在EOF之前遇到一个，则为$ b。否则它将返回?? 1。
<结束报价>
我们回到这里来看错误分析问题，这个问题我已经提到了很多年以来一直在提及的问题。返回
-1表示发生了一些错误，但我不会告诉你哪个
是糟糕的设计！
此函数可能有多个错误，应该在函数的返回值中区分，即应该有其他返回
值用于向用户发送信号错误。 Lcc-win32实现了这个
函数并返回：
-5没有内存可用于分配行
-4行指针指向一个缓冲区，但是n是< = 0.这是传入参数的错误。
>
In the documents presented in the post Portland meeting
of the C standards comitee
http://www.open-std.org/jtc1/sc22/wg14/
there is a document called ISO/IEC WDTR 24731-2,
Specification for Safer C Library Functions a??
Part II: Dynamic Allocation Functions
In that document we have:
ssize_t getdelim(char **restrict lineptr,
size_t *restrict n, int delimiter, FILE *stream);
We read:
< quote >
Upon successful completion the getdelim function shall return the number
of characters written into the buffer, including the delimiter character
if one was encountered before EOF. Otherwise it shall return a??1.
< end quote >
We come back here to the error analysis problem, a problem that I
have been mentioning since ages and comes again and again. Returning
-1 to indicate "some error occurred but I will not tell you which"
is BAD DESIGN!
This function can have several errors that should be distinguished in
the return value of the function, i.e. there should be other return
values for signaling errors to the user. Lcc-win32 implements this
function and returns:
-5 No memory left for allocating the line
-4 Line pointer points to a buffer but n is <= 0. This is an error in
the incoming arguments.
如果缓冲区是以这种方式分配的，则不是：
n = 0;
buffer = malloc（0） ;
ITYM" ...但是n等于0"
Not if the buffer is allocated this way:
n = 0;
buffer = malloc(0);
ITYM "... but n equals 0"
-3 n参数是NULL
-3 The n parameter is NULL
ITYM null，这不是问题。
ITYM null, and that''s not a problem.
-2 LinePointer参数是NULL
-2 The LinePointer parameter is NULL
如果n等于0也没问题。
Not a problem either, if n equals 0.
-1没有文件结束任何字符读取。
这是一个更详细的错误报告，允许该函数的
用户区分不同的错误
条件。令人遗憾的是，提出更安全的文件令人遗憾。函数
不做错误分析，这是更安全的b / b
编程的重要部分。
-1 End of file without any characters read.
This is a much more detailed error reporting, that allows the
user of the function to discriminate between the different error
conditions. It is sad that a document that proposed "safer" functions
doesn''t do the error analysis that is an essential part of safer
programming.
我注意到列出的下一个函数，getline，
ssize_t getline（char ** lineptr，size_t * n，FILE * stream）;
与我的line_to_string函数具有完全相同的功能，
（我已经发布了足够的时间来讨厌最近
http://groups-beta.google.com/group /...694880f515e317 ）
但返回值不同。
line_to_string在文件结束时返回EOF
在读取换行符之前
或输入错误。
feof和ferror可用于确定哪一个。
文件结尾没有读取任何字符
是在读取换行符之前的特定情况。
如果没有足够的内存，line_to_string将返回0.
如果*函数中的* size小于2，那么
然后是e也是一个字符后推。
否则，line_to_string返回
写入缓冲区的字符数
就像getline一样。
line_to_string总是在缓冲区留下一个字符串，
除非函数中的* size为零。
缓冲情况下的后推情况和无字符串，
绝对可以避免，通过提供一个多个字节的缓冲区来支付
， />
调用line_to_string。
-
pete
I''ve noticed that the next function listed, getline,
ssize_t getline(char **lineptr, size_t *n, FILE *stream);
has exactly the same functionality as my line_to_string function,
(which I''ve posted enough times to be annoying recently
http://groups-beta.google.com/group/...694880f515e317)
but the return values are different.
line_to_string returns EOF upon an end of file condition
before reading a newline, or input error.
feof and ferror can be used to determine which.
"End of file without any characters read"
is a specific case of "before reading a newline".
line_to_string returns 0 if there is not enough memory.
if *size is less than 2 within the function,
then there is also a character pushback.
Otherwise, line_to_string returns
"the number of characters written into the buffer"
just like getline.
line_to_string always leaves a string in the buffer,
unless *size is zero within the function.
Both the pushback case and the no string in the buffer case,
can be definitely avoided,
by supplying a buffer with more than one byte,
in the call to line_to_string.
--
pete
peteaécrit：
pete a écrit :
jacob navia写道：
jacob navia wrote:
>>这个函数可能有几个错误应该在功能的返回值中区分，即应该有其他返回值，以便向用户发送信号错误。 Lcc-win32实现了这个功能并返回：
-5没有剩余的内存用于分配行
-4行指针指向缓冲区但是n是< = 0。这是传入参数中的错误。
>>This function can have several errors that should be distinguished in
the return value of the function, i.e. there should be other return
values for signaling errors to the user. Lcc-win32 implements this
function and returns:
-5 No memory left for allocating the line
-4 Line pointer points to a buffer but n is <= 0. This is an error in
the incoming arguments.
如果缓冲区是这样分配的，则不是：
n = 0;
buffer = malloc（0）;
Not if the buffer is allocated this way:
n = 0;
buffer = malloc(0);
这太荒谬了...现在有什么意义得到零线
长度??? ？这肯定是一个错误！
This is ridiculous... Now what is the point of getting a line of zero
length???? This is surely an error!
ITYM" ...但是n等于0"
ITYM "... but n equals 0"
>> -3 n参数为NULL
>>-3 The n parameter is NULL
ITYM null，这不是问题。
ITYM null, and that''s not a problem.
根据规格，n参数永远不应为NULL ...
The n parameter should never be NULL according to the specs...
>
>
>> -2 LinePointer参数为NULL
>>-2 The LinePointer parameter is NULL
不是问题或者，如果n等于0.
Not a problem either, if n equals 0.
否，因为它不能将结果返回到* n !!!它会读取
字符，但它不能返回它们。这是胡说八道......
No, because it can''t return the result into *n!!! It will read
chars but it can''t return them. This is nonsense...
jacob navia写道：
jacob navia wrote:
>
peteaécrit：
>
pete a écrit :
jacob navia写道：
jacob navia wrote:
>此函数可能有几个错误<应该在函数的返回值中区分，即应该有其他返回值，以便向用户发送信号错误。 Lcc-win32实现了这个功能并返回：
-5没有剩余的内存用于分配行
-4行指针指向缓冲区但是n是< = 0。
这是传入参数
中的错误。
>This function can have several errors
that should be distinguished in
the return value of the function, i.e. there should be other return
values for signaling errors to the user. Lcc-win32 implements this
function and returns:
-5 No memory left for allocating the line
-4 Line pointer points to a buffer but n is <= 0.
This is an error in
the incoming arguments.
如果缓冲区是这样分配的，则不是：
n = 0;
buffer = malloc（0） ;
Not if the buffer is allocated this way:
n = 0;
buffer = malloc(0);
这太荒谬了...现在有什么意义得到零线
长度????这肯定是一个错误！
This is ridiculous... Now what is the point of getting a line of zero
length???? This is surely an error!
得到一条零长度的线，
就是这不是函数的工作方式。
回想一下文档的标题：
第二部分：动态分配函数
调用函数的一种非常简单的方法是：
ssize_t rc;
char * buffer = NULL;
size_t size = 0;
rc = getdelim（& buffer，& size，''\ n''，stdin）;
在这篇文章中：
http://groups-beta.google.com/ group / ... a8ef6a9d40e578
line_to_string以这种方式被调用。
/ *
* * INITIAL_BUFFER_SIZE可以是任意数字。
**较低的数字更有可能是
**从malloc获得非NULL返回值。
**更高的数字更有可能阻止
**需要的时间。
* /
#define INITIAL_BUFFER_SIZE 0
buff_size = INITIAL_BUFFER_SIZE;
buff_ptr = malloc（buff_size）;
if（buff_ptr == NULL&& buff_size！= 0）{
printf（" malloc（％lu）== NULL \ n"，（long unsigned）buff_size）;
exit（EXIT_FAILURE） ;
}
rc = line_to_string（stdin，& buff_ptr，& buff_size）
The point of getting a line of zero length,
is that that''s not how the function works.
Recall the title of the document:
Part II: Dynamic Allocation Functions
A very simple way to call the function is:
ssize_t rc;
char *buffer = NULL;
size_t size = 0;
rc = getdelim(&buffer, &size, ''\n'', stdin);
In this post:
http://groups-beta.google.com/group/...a8ef6a9d40e578
line_to_string is called in just exactly that way.
/*
** INITIAL_BUFFER_SIZE can be any number.
** Lower numbers are more likely
** to get a non-NULL return value from malloc.
** Higher numbers are more likely to prevent
** any further allocation from being needed.
*/
#define INITIAL_BUFFER_SIZE 0
buff_size = INITIAL_BUFFER_SIZE;
buff_ptr = malloc(buff_size);
if (buff_ptr == NULL && buff_size != 0) {
printf("malloc(%lu) == NULL\n", (long unsigned)buff_size);
exit(EXIT_FAILURE);
}
rc = line_to_string(stdin, &buff_ptr, &buff_size)
ITYM" ...但是n等于0"
ITYM "... but n equals 0"
> -3 n参数为NULL
>-3 The n parameter is NULL
ITYM null，这不是问题。
ITYM null, and that''s not a problem.
根据规格，n参数永远不应为NULL ...
The n parameter should never be NULL according to the specs...
我误读为* n等于NULL。
从你使用的'n是< = 0"
我假设你的意思是n是缓冲区大小
而不是指向大小的指针。
I misread that as *n being equal to NULL.
From your usage of "n is <= 0"
I assumed you meant n to be the buffer size
rather than the pointer to the size.
> -2 LinePointer参数是NULL
>-2 The LinePointer parameter is NULL
也没问题，如果n等于0.
Not a problem either, if n equals 0.
不，因为它可以不会把结果归还给* n !!!它会读取
字符，但它不能返回它们。这是胡说八道...
No, because it can''t return the result into *n!!! It will read
chars but it can''t return them. This is nonsense...
同样，我的意思是如果* n等于零
我也误读了LinePointer来表示* LinePointer。 br />
-
pete
Likewise, I meant if *n equals zero
and I also misread LinePointer to mean *LinePointer.
--
pete
这篇关于getdelim：错误的规格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
