[Libwebsockets] most recent master commit / breaking changes?

Joel Winarske joel.winarske at gmail.com
Fri Mar 17 04:17:25 CET 2017


The code was in one of my plugins.  It just had warnings I chose to
ignore.  My bad.

Regarding fstat my exercise indicates that fstat only likes the file handle
from open(), opposed to CreateFile().  Running in the debugger, fstat fires
an exception; which I originally listed.  stat was used before, and this
didn't require a file handle.

Also stat doesn't require an opened file, where fstat does.  When
determining 304 if you don't need to open a file, better perf right?
Especially with a SPI, MMC. or eMMC memory device.

My vote is to factor out fstat and avoid opening the file unless actually
needed.


On Thu, Mar 16, 2017 at 8:03 PM, Andy Green <andy at warmcat.com> wrote:

>
>
> On 03/17/2017 10:39 AM, Joel Winarske wrote:
>
>> The fstat change came in with 19cc7acb24a1bb402ef3260efa2b64b9357b746a -
>> fops-zip
>>
>
> That fstat change is not special for WIN32 and it works fine on Linux;
> fstat() should be the same on Windows.
>
> It looks like the fd is invalid, but that doesn't make sense since if it
> can't find the file it will return a NULL fop_fd and we check for that.
>
>
>>
>> On Thu, Mar 16, 2017 at 7:26 PM, Joel Winarske <joel.winarske at gmail.com
>> <mailto:joel.winarske at gmail.com>> wrote:
>>
>>     Regarding 1, thank you for pointing out the API change.  I
>>     resolved this.  I reverted code changes on 2 to check, and fstat
>>     is still failing.
>>
>>
> OK... it should have blown compiler errors though, since the args would
> not match the new declaration in the header.  So that suggests maybe still
> problems with your local lws tree diverged from mine.
>
> git pull is good for following trees with a consistent history. It's not
> really useful following master.  Appveyor and Travis only tell me I have
> problems after I push stuff, so there is a constant trickle of fixes coming
> that way.  Rather than mess up the history with "uhhh... fix NO_SERVER"...
> "ughhh... fix that fix", I fix whatever I was pushing directly and repush
> it.  Sometimes I will refactor what I have been working on and pushing over
> several days, or change the order of the patches in the history (on master,
> I leave the vx.y-stable branches to have a consistent history).
>
> The right way for following this kind of tree is, eg,
>
>  $ git fetch https://github.com/warmcat/libwebsockets +master:m
>
> This teleports the remote master into a local branch "m".  It makes no
> effect at all on your local checked-out branch.  You can check what the
> differences are with your local checked-out branch
>
>  $ git diff --stat m
>
> If you want to replace your local checked-out lws with "m" - it replaces
> everything with exactly "m", losing any changes you may have made to lws
>
>  $ git reset --hard m
>
> If you think you might want your local changes, you can use
>
>  $ git diff m > changes.patch
>
> first to save the differences, or you can leave your old branch intact and
> move to a new branch set to m
>
>  $ git branch lws7
>  $ git checkout lws7
>  $ git reset --hard m
>
> -Andy
>
>
>>     On Thu, Mar 16, 2017 at 5:43 PM, Andy Green <andy at warmcat.com
>>     <mailto:andy at warmcat.com>> wrote:
>>
>>
>>
>>         On 03/17/2017 05:20 AM, Joel Winarske wrote:
>>
>>             Hi Andy,
>>             I just did a pull on master, and now am seeing a couple
>>             issues with things on Windows:
>>             1. When stepping into lws_vfs_file_open *flags ==
>>             0xcccccccc, not 0. No idea what's up with this. It fails,
>>             unless I update the value to 0 in the debugger.
>>             uint32_t flags = LWS_O_RDONLY;
>>             fd = lws_vfs_file_open(lws_get_fops(vhd->context), file,
>>             &filesize, &flags);
>>
>>
>>         Where is this code from?  It doesn't seem to exist in my tree.
>>
>>         lws_vfs_file_open() now looks like this
>>
>>         LWS_VISIBLE LWS_EXTERN lws_fop_fd_t LWS_WARN_UNUSED_RESULT
>>         lws_vfs_file_open(const struct lws_plat_file_ops *fops, const
>>         char *vfs_path,
>>                   lws_fop_flags_t *flags);
>>
>>             if (fd == NULL) {
>>             lwsl_notice("file not opened %s\n", file);
>>             return -1;
>>             }
>>
>>             2.  Serving is somehow broken.  I haven't changed my
>>             config file.  Is there a breaking change, or modification
>>             required for conf file I missed?  The file is present.
>>
>>             [2017/03/16 14:08:58:2111] INFO: Method: GET request for
>>             '/ui/index.html'
>>             [2017/03/16 14:08:58:2121] INFO: client indicates GZIP is
>>             acceptable
>>             [2017/03/16 14:08:59:6864] INFO: unable to stat
>>             C:/etc/lwsws/www/ui/index.html
>>             [2017/03/16 14:08:59:6874] INFO: LWS_CALLBACK_HTTP closing
>>
>>             I get a break point on the last line.  This never happened
>>             before:
>>             template <typename StatStruct>
>>             static int __cdecl common_fstat(int const fh, StatStruct*
>>             const result) throw()
>>             {
>>                 _VALIDATE_CLEAR_OSSERR_RETURN(result != nullptr,
>>             EINVAL, -1);
>>                 *result = StatStruct{};
>>
>>                 _CHECK_FH_CLEAR_OSSERR_RETURN(fh, EBADF, -1);
>>                 _VALIDATE_CLEAR_OSSERR_RETURN(fh >= 0 && fh <
>>             _nhandle, EBADF, -1);
>>
>>
>>         Is this possibly a fallout from 1)?
>>
>>         -Andy
>>
>>
>>
>>             Thanks,
>>             Joel
>>
>>
>>             _______________________________________________
>>             Libwebsockets mailing list
>>             Libwebsockets at ml.libwebsockets.org
>>             <mailto:Libwebsockets at ml.libwebsockets.org>
>>             https://libwebsockets.org/mailman/listinfo/libwebsockets
>>             <https://libwebsockets.org/mailman/listinfo/libwebsockets>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170316/98635bdc/attachment-0002.html>


More information about the Libwebsockets mailing list