On 10/25/2017 09:49 PM, Collin L. Walling wrote:
>>> - sccb->h.length = sizeof(WriteEventData) + len;
>>> + for (p = str; *p; ++p) {
>>> + if (data_len > SCCB_DATA_LEN - 1) {
>>> + return -EFBIG;
>>> + }
>> We could also do a partial write or do more that one
>> sclp_service_call calls.
>>
>> I don't think EFBIG is entirely correct here. From the man page:
>> """
>> EFBIG An attempt was made to write a file that exceeds the
>> implementa-
>> tion-defined maximum file size or the process’s file size
>> limit,
>> or to write at a position past the maximum allowed offset.
>> """
>>
>> That's not what we have here IMHO.
>
>
> From my perspective, the error code was a tie between EFBIG (consider
> max sccb size as the maximum allowed offset) and ENOSPC:
>
>
> """
> ENOSPC The device containing the file referred to by /fd/has no room
> for the data.
> """
>
From where I stand, the file behind the fd is the VT220 terminal you
talk to via sclp_service_call(SCLP_CMD_WRITE_EVENT_DATA, sccb) -- you
can check the AR).
In the end, the target scope (in sense of expected client
code) of this function very limited, and AFAIU does not necessarily
care about error codes (see sclp_print). So basically anything is fine
with me, because it does not really matter -- but just because it does
not really matter.
Halil
>
> (consider "the file" as the sccb data buffer)
>
> However, I extremely doubt we'll ever encounter an overflow from
> printing during the bios (why would we print something that large?)
> ... perhaps the check is redundant?
