<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 2:04 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi Holger,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
> On 23 Sep 2016, at 14:40, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
><br>
><br>
> I suggest that you try this first by making your own plugin separate from FilePlugin.<br>
> If the idea proves useful in a general way, then consider adding it to FilePlugin.<br>
><br>
> FilePlugin is one of a small number of essential plugins that needs to be implemented<br>
> when bringing up a VM an a new platform, so it is generally a good idea to resist<br>
> the temptation to add features there.<br>
<br>
</span>Fair enough but the other plugin would need to have access to struct SQFile<br>
and without plugin dependencies and ABI versioning doing it in another plugin<br>
looks rather fragile.<br>
<br>
fdopen is not in C99 but the other primitive does not add burden on porting as<br>
a valid FILE* ptr is passed in and used. No additional API calls are made. Any<br>
objection to this primitive?<br></blockquote><div><br></div><div>Not from me. Seems like a very good idea. Feel free to contribute an implementation.</div><div><br></div><div>I think we should also provide a primitive that answers the file descriptor associated with the fileID. </div></div></div></div></blockquote><div><br></div><div><br></div><div>Yes! I was thinking about this one too some hours ago. I workaround it (for my usecase) because I FIRST got the FD (from pipe()) and then got the fileID...so I could simply "remember it" at my side. But sure, getting the fd from a fileID would be very nice to have too. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We could also provide primitives that set and get the FILE * structure if the platform has something analogous. This pair of primitives could either fail if the platform fdoesn't use this (Windows) or degenerate to the file descriptor access primitives. What do you think?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>>> From your previous email regarding sqFileReadIntoAt(), I think that you have<br>
> already noticed some rather questionable features that have crept into this<br>
> plugin over the years ;-)<br>
<br>
</span>yes, the ungetc for stdio seems rather odd.<br>
<span><font color="#888888"><br>
holger</font></span></blockquote></div><br><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>