> Oh. If there's actually a standard somewhere that says it's not
> null-terminated, then code that is expecting it to be so is just
> wrong. No need to change anything in ecpg, IMO.
As I said I haven't checked if this detail is actually in there, but I
guess it was because there is a reason why
Michael Meskes writes:
> With "supposed" I was referring to the standard that defines SQLCA.
Oh. If there's actually a standard somewhere that says it's not
null-terminated, then code that is expecting it to be so is just
wrong. No need to change anything in ecpg, IMO.
> > Why do you think there should be one? My memory might be wrong but
> > I
> > don't think it's supposed to be a null terminated string.
>
> That field is defined as char[5] in struct sqlca_t, so the intent is
> clearly that it not be null terminated. However, it looks to me like
> there'd be a
Michael Meskes writes:
>> In the function ECPGnoticeReceiver, we use the stncpy function copy
>> the
>> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
>> the size
>> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the
>> previous strcmp function, the sqlstate
> When we reviewed the ecpg code,we found the array seem not have the
> end
> character('\0') after using the strncpy function.
True.
> In the function ECPGnoticeReceiver, we use the stncpy function copy
> the
> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
> the size
> of
Hi
When we reviewed the ecpg code,we found the array seem not have the end
character('\0') after using the strncpy function.
In the function ECPGnoticeReceiver, we use the stncpy function copy the
sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as the size
of 5, and the copy si
