Bug 179511 - [WPE] GLContextEGLWPE.cpp:44:96: error: invalid cast from type ‘GLNativeWindowType {aka long long unsigned int}’ to type ‘EGLNativeWindowType {aka unsigned int}
Summary: [WPE] GLContextEGLWPE.cpp:44:96: error: invalid cast from type ‘GLNativeWindo...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WPE WebKit (show other bugs)
Version: Other
Hardware: PC Linux
: P2 Normal
Assignee: Carlos Alberto Lopez Perez
URL:
Keywords:
Depends on:
Blocks: 178894
  Show dependency treegraph
 
Reported: 2017-11-09 16:34 PST by Michael Catanzaro
Modified: 2017-11-20 07:58 PST (History)
10 users (show)

See Also:


Attachments
Patch (2.18 KB, patch)
2017-11-15 17:36 PST, Carlos Alberto Lopez Perez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2017-11-09 16:34:57 PST
When building for 32-bit ARM:

./platform/graphics/egl/GLContextEGLWPE.cpp: In static member function ‘static void* WebCore::GLContextEGL::createWindowSurfaceWPE(EGLDisplay, EGLConfig, GLNativeWindowType)’:
./platform/graphics/egl/GLContextEGLWPE.cpp:44:96: error: invalid cast from type ‘GLNativeWindowType {aka long long unsigned int}’ to type ‘EGLNativeWindowType {aka unsigned int}’
     return eglCreateWindowSurface(display, config, reinterpret_cast<EGLNativeWindowType>(window), nullptr);

So, that cast is clearly illegal. GLNativeWindowType is larger than EGLNativeWindowType, so it's not safe to cast in that direction.

I notice that GLNativeWindowType is defined oddly in GLContext.h:

#if USE(EGL) && !PLATFORM(GTK) && !PLATFORM(WPE)
#include "eglplatform.h"
typedef EGLNativeWindowType GLNativeWindowType;
#else
typedef uint64_t GLNativeWindowType;
#endif

I'm genuinely uncertain where the declaration of EGLNativeWindowType is coming from, but I see this in ANGLE's eglplatform.h:

#elif defined(USE_OZONE) || defined(USE_WPE)

typedef intptr_t EGLNativeDisplayType;
typedef intptr_t EGLNativeWindowType;
typedef intptr_t EGLNativePixmapType;

And of course, intptr_t is a 32-bit type. I have no clue how this is supposed to work.
Comment 1 Carlos Alberto Lopez Perez 2017-11-10 08:26:29 PST
(In reply to Michael Catanzaro from comment #0)
> I'm genuinely uncertain where the declaration of EGLNativeWindowType is
> coming from, but I see this in ANGLE's eglplatform.h:
> 

EGLNativeWindowType is declared in /usr/include/EGL/eglplatform.h and has different definitions depending on the EGL platform you have defined (GBM, WaylandEGL, X11, etc)


I think ANGLE headers should not be used for building this file.
Comment 2 Michael Catanzaro 2017-11-10 09:50:32 PST
I don't know if ANGLE headers are actually used or not. I don't know where the definition of EGLNativeWindowType is coming from. But I'd be surprised that we have it defined to be intptr_t there if we're not using it.
Comment 3 Carlos Alberto Lopez Perez 2017-11-15 17:08:08 PST
I have been bitten by this, so I have checked it.

I think this started to happen with r217208 <https://trac.webkit.org/r217208>

Patch incoming ..
Comment 4 Carlos Alberto Lopez Perez 2017-11-15 17:36:25 PST
Created attachment 327039 [details]
Patch
Comment 5 Build Bot 2017-11-15 17:38:28 PST
Attachment 327039 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:3:  Please consider whether the use of security-sensitive phrasing could help someone exploit WebKit: invalid cast  [changelog/unwantedsecurityterms] [3]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 6 Michael Catanzaro 2017-11-16 09:30:15 PST
Thanks. I'm not qualified to review this; please ask Miguel and Zan.
Comment 7 Carlos Alberto Lopez Perez 2017-11-16 17:09:26 PST
(In reply to Carlos Alberto Lopez Perez from comment #3)
> 
> I think this started to happen with r217208 <https://trac.webkit.org/r217208>
> 

When I wrote that I didn't noticed the age of the commit (6 months ago).. 
And IIRC I did ARMv7 builds of WPE trunk 1-2 months ago.

So I guess something else than r217208 caused this

In any case I still think the attached patch is ok, so any review of it is appreciated.
Comment 8 WebKit Commit Bot 2017-11-20 07:58:00 PST
Comment on attachment 327039 [details]
Patch

Clearing flags on attachment: 327039

Committed r225051: <https://trac.webkit.org/changeset/225051>
Comment 9 WebKit Commit Bot 2017-11-20 07:58:02 PST
All reviewed patches have been landed.  Closing bug.